Specifying Secure Transport Layers

Security architectures often make use of secure transport protocols to protect network messages: the transport protocols provide secure channels between hosts. In this paper we present a hierarchy of specifications for secure channels. We give trace specifications capturing a number of different confidentiality and authentication properties that secure channels might satisfy, and compare their strengths. We give examples of transport layer protocols that we believe satisfy the channel specifications. A popular technique for designing a security architecture is to rely on a secure transport layer to protect messages on the network, and provide secure channels between different hosts; see e.g. [9, 12, 13]. This can simplify the design of the security architecture: the designer can use an offthe-shelf secure transport protocol, such as TLS, to provide secrecy and authentication guarantees; the architecture can then provide additional security guarantees in a higher layer, which we refer to as the application layer. In such circumstances it is important to understand what is required of the secure transport protocol, and, conversely, what services are provided by different protocols. TLS provides strong guarantees; however, it is computationallyexpensive, and so in some circumstances a simpler protocol might suffice. This layered approach can also simplify the analysis of the architecture. Rather than modelling explicitly the design of the secure transport layer protocol, one can simply model the services it provides, treating it as an abstract secure channel. This results in a simpler model that concentrates on the application layer. This is the standard approach to analysing layered architectures in other settings. The alternative, of explicitly modelling the functionality of both layers, would lead to unnecessary added complexity. The aim of this paper, therefore, is to improve our understanding of security guarantees that might be provided by secure channels. We capture security properties using CSPstyle trace specifications, building on the work of Broadfoot and Lowe [3]. Our formalism will allow us to compare the strengths of different secure channels: if an architecture is correct when it uses a particular secure channel, it will still be correct when it uses a stronger channel. In Section 1 we formalise an abstract model of a layered network, and relate it to a concrete network. We describe the sets of valid traces that our network accepts, and we provide a framework for specifying secure channels. In Section 2 we describe how we flag confidential channels in a system, and define the properties of a confidential channel in terms of the relation between the intruder’s knowledge in our abstract model and the intruder’s knowledge in the concrete model. In Section 3 we define the building blocks we use to create our hierarchy. These building blocks progressively disallow different aspects of the intruder’s behaviour, and can be combined to create different channels. Not all combinations are distinct: in many cases, several different compositions of the building blocks will allow essentially the same behaviour (they simulate one another); we collapse such cases, and reach a hierarchy of eleven secure channels. In Section 4 we consider several of the secure channels from the hierarchy in more detail, and relate them to real-world secure transport protocols. In Section 5 we consider channel specifications that tie different messages into a single connection. We specify a session property that binds messages into a single session, and a stronger stream property that not only ensures that messages are not moved from one session to another, but also guarantees that the order messages are received in is the same as that in which they were sent. In Section 6 we define a simulation relation on systems of secure channels, based on the traces of specifications as they are viewed by the honest agents. Specification Spec1 simulates specification Spec2 if Spec1 allows at least as many traces as viewed by honest agents. We use the simulation relation to define an equivalence relation. In Section 7 we use the equivalence relation to prove the equivalence of an alternative form for each of our channel specifications. Each alternative form describes the necessary behaviour that must precede a receive event, rather than blocking the intruder’s behaviour. Finally, in Section 8 we conclude, and discuss alternative approaches to specifying secure channels, and several pieces of related work. 1. Channels, formally In this section we formalize our model of an abstract network and its relation to a concrete network. We use CSPstyle trace notation: see Appendix A. The abstract network is defined in terms of honest agents, who send and receive messages, and an intruder, who has several events he can use to manipulate the messages being passed on the network, and who can also send and receive messages. Our model reflects the traditional internet protocol stack, but we add a new layer between the transport layer and the application layer: the secure transport layer. We abstract all of the layers beneath the secure transport layer into a network layer. Our model uses entities at two interfaces: between the application layer and the secure transport layer, and between the secure transport layer and the underlying network. The application layer is the layer in which agents establish channels, and send and receive messages. The secure transport layer contains protocol agents, which translate the higher level events into lower level events (e.g. by encrypting or signing messages), and vice versa (e.g. by decrypting messages or verifying signatures). See Figure 1. Most of the events are at the interface between the application layer and the secure transport layer, and describe the application layer data: these events are enough to capture authentication guarantees. The model also uses events at the interface between the secure transport layer and the underlying network, which describe the network messages: these events are necessary to capture confidentiality properties formally. Describing a channel We assume a set Identity of agent identities. Each identity is either considered Honest (i.e. the agent follows the application-layer protocols) or Dishonest (i.e. the agent is under the intruder’s control). We also assume a set Role of roles in the applicationlayer protocols, ranged over by Ri, Rj , etc. Each role in an application protocol will exchange a series of messages with some of the other roles in the protocol. We assume that the roles used by different protocols are distinct. An Agent is an identity taking a role: Agent =̂ Identity× Role. We use A, A′, B, B′, etc., to range over either Identity or Agent, as convenient; we use I as a dishonest identity (or agent). We abuse notation by sometimes writing Honest for Honest × Role, and similarly for Dishonest. We write R̂i for Identity×Ri. receiveTL